Introduction to
Web Services Testing

The Internet is a mesh of networks where hundreds of millions of computers of different types running on different operating systems are connected to each other. To ensure messages and data flow smoothly between them, we use web services.

What is a Web Service?

On the World Wide Web, a web service is a standardised method for propagating messages between client and server applications. A web service is a software module that is intended to carry out a specific set of functions. Web services in cloud computing can be found and invoked over the network.

It is a set of open protocols and standards that allow data to be exchanged between different applications or systems.

Software programs use web services through a variety of programming languages that run on a variety of platforms to facilitate a smooth exchange of data via computer networks such as the Internet in a similar way to inter-process communication on a single computer.

In other words, any software, application, or cloud technology that uses these standardised web protocols (like HTTP or HTTPS) to connect, interoperate, and exchange data messages – commonly XML (Extensible Markup Language) – across the internet is considered a web service.

How Web Services Work?

A web service works on the principle of Request and Response. These are typically in the form of XML, though other types are also supported. A client invokes a web service by submitting an XML request, which the service responds with an XML response.

What is the difference between an API and a web service?

There is a general consensus that web services and APIs are one and the same thing. This is not correct!

While all web services are APIs, not all APIs are web services.

Web service is a collection of open-source protocols and standards used for exchanging data between computer systems or software applications, whereas API is a software interface that allows two applications to interact with each other without any user involvement.

The other differences API and web services are:

• Web service is used for REST, SOAP, and XML-RPC for communication, while API is used for any style of communication.
• Web service supports only HTTP protocol. API supports both HTTP and HTTPS protocol.
• Web service supports XML, while API supports XML and JSON.

Why is Web Service Needed?

Most softwares today works on principles of request and response. Users send requests for the data they want to see and receive the response. It is not advisable or feasible to develop each and every software because they are already developed and are ready as plug and play versions.

For example:

You want to check the flight availability from city A to city B. You can buy the services from the people who already are well-established in processing and publishing such kind of data rather than developing the entire application, collecting data, processing it and then finding the usefulness of it.

The same goes with weather forecasts, stock markets, sports scores or any other data.

What is Web Service Testing?

Just like any other piece of software, Web Services also requires to be validated so we can ensure the functionality, reliability, performance, and security of an API (Application Program Interface) works as intended.

You can test a Web service manually by using tools like SoapUI or Postman (available as an addon to chrome ) or create your own automation code. EIther way, it is important to test if the Web service is giving a correct response to the request in the desired timeframe.

Automating Web Services Testing

Automating Web Services testing is critical for testing web applications in an efficient manner. Automation helps quality test engineers study how specific web services work in varying situations.

Web services automation testing allows engineers to isolate and automate one aspect of a web service, whether it be load testing, API testing, etc., and see what factors affect performance and behaviour.

At the end of the day, web services test automation tools help developers and designers confirm that web applications meet business standards and requirements while providing a quality User Interface and high functionality for end-users.

How are Web Services Implemented?

Before beginning automation for Web services, one should understand how web services are implemented. This knowledge will certainly help when automating them.

Web services are nothing but communication enablers between two machines, software applications or web applications. There are two main ways that web services are implemented: SOAP and REST.

SOAP

SOAP stands for Simple Object Access Protocol. SOAP is a standard web services protocol that is used to send, receive, and respond to web service requests. XML format is used to send and receive web service requests. This allows data to remain independent from the platform that is being used.

Example: A SOAP request to fetch user data of user “Mike”

<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:sch="http://www.soapexample.com/xml/users">
	<soapenv:Header/>
	<soapenv:Body>
		<sch:UserDetailsRequest>
			<sch:name>Mike</sch:name>
		</sch:UserDetailsRequest>
	</soapenv:Body>
</soapenv:Envelope>

The response, just like the request, consists of a SOAP envelope and a SOAP body. The SOAP body represents the requested user data.

<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header/>
	<soapenv:Body>
		<ns2:UserDetailsResponse
			xmlns:ns2="http://www.soapexample.com/xml/users">
			<ns2:User>
				<ns2:name>Mike</ns2:name>
				<ns2:age>33</ns2:age>
				<ns2:city>Cambridge</ns2:city>
			</ns2:User>
		</ns2:UserDetailsResponse>
	</soapenv:Body>
</soapenv:Envelope>

REST

REST is an acronym for Representational State Transfer. REST follows HTTP protocol with an emphasis on client and service interaction. Instead of using XML like SOAP, REST uses simple URLs and built-in HTTP headers to relay metadata between web applications.

Representational State Transfers have a limited amount of operations when compared with SOAP.

Example: A REST request to fetch user data of user “Mike”

A REST API accepts GET parameters from the URI.

GET https://restexample.com/users?name=John

The user is represented in JSON like this:

{ 
"name": "Mike", 
"age": 33, 
"city": "Cambridge" 
}

Automating Web Services Testing Challenges

Just with the decision that web services need to be automated does not make the case easy. Automating web services is complex and you should be well versed with automation techniques, tools and knowledge of how web services work.

While planning for web service automation, the following challenges are faced and organisations should have plans to tackle them:

• Setting up Metrics to measure
• Finding the starting point
• Making sure Code coverage is high
• A robust and efficient QA process

Setting up Metrics to measure

KPI (Key Performance Indicators) are important criteria to assess the value of your quality assurance tests in the information they provide. There are decisions that are taken by the team with data getting produced through the automated tests. These will drive the direction of the development projects and the overall success of your business.

Setting up key performance indicators for your team is very important as it measures success.

Your development, testing, and other teams need to agree on what success looks like and which key performance indicators are the most important measure of it.

With a clear vision and solid KPIs, web service test automation can be a long-term benefit to your organisation.

Finding the starting point

When to start automation remains the biggest question in front of all developers. Setting goals and agreeing on measurables will help define your starting point, but you’ll still need to create a web services automation testing strategy. We answer this tricky question by using one of the two popular philosophies in quality testing. The first is risk-based testing, and the second is the Test Automation Pyramid.

A risk-based testing approach highlights the riskiest areas of a web service in terms of the costs involved or the probability of failure; often, these two concerns overlap. This approach structures web service test automation based on the areas that present the most risk.

On the other hand in the Test Automation Pyramid approach, we structure the web services test automation differently. In this approach, organisations structure their web services testing like a pyramid. In most cases, the Test Automation Pyramid begins with unit tests, then moves on to integration, component, and API testing, and finally, ends with UI testing.

Both of these approaches are fine strategies to optimise your web services’ testing resources.

Making sure Code coverage is high

The code coverage by the automation scripts determines the success or failure of any automated web services testing. Code will likely be integrated regularly as you work on a web application.

The challenge is to ensure that your test cycles are optimised to include the code changes being made, so errors are not potentially missed. Web applications need to be tested against multiple different combinations of browsers, operating systems, and devices to ensure high quality.

Robust and Efficient QA Process

The QA team and management team need to be organised and on the same page when it comes to the QA process and the desired results. Clear communication lines at every stage of the QA process are just as important as the automation tools being used to streamline your web services testing.

The project should have a clearly defined RACI matrix and enough stress should be done on the reporting part as well.

Web Services Automation Testing

Web Services Automation Testing involves following steps –

1. Preparing the WSDL file
2. Finding what the particular web service provides
3. Preparing the XML request which we need to send
4. Determine the response XML format
5. Writing code to send request and validate the response

E.g. first 4 steps are explained via a code snippet

There are lots of WebService Test tools available to test web service. SoapUI is one of the popular API tools which will help us to test SOAP web services. In fact you can use any programming language which is capable of sending the XML request to the web service provider application over the http and able to parse and validate the response XML against the expected result. Java is a huge language preferred when testers want to write scripts from scratch.

Summary

• Software Applications communicate and exchange data with each other using a WebService
• SOAP and REST are 2 popular protocols to create a WebService
• SOAP supports XML based data exchange
• REST supports XML, Json or exchange of data in simple URL for WebServices API Testing.
• WSDL is a XML based language which will be used to describe the services offered by a web service. SOAP is defined using WSDL.

To test WebService you can

• Create your own code. For instance use Axis2 API for Java
• Use WebService Test Automation tools like SoapUI
• Automation Tools like SoapUI or Postman will jumpstart your Web Services Automation Testing efforts, will require less coding effort compared to creating your own code using Axis2 API